Software Vault: The Gold Collection/Software Vault - The Gold Collection (American Databankers) (1993).ISO/cdr12/v93n03y.zip/V93N034.IBM

Internet Message Format | 1993-05-05 | 29KB

From:    WF02::IN%"[e-mail]"  9-MAR-1993 01:43:36.64
To:    James Gerber <[e-mail]>
CC:
Subj:    Info-IBMPC Digest V93 #34

Return-path: $$INFOPC
 <@WS5.CIS.TEMPLE.EDU:$$[e-mail]>
Received: from JNET-DAEMON by GRAD.CIS.TEMPLE.EDU; Tue, 9 Mar 93 00:40 EST
Received: From TEMPLEVM(MAILER) by TMPLCIS with Jnet id 5116 for
 GERBER@TMPLCIS; Tue,  9 Mar 93 00:40 EDT
Received: from TEMPLEVM.BITNET (NJE origin LISTSERV@TEMPLEVM) by VM.TEMPLE.EDU
 (LMail V1.1d/1.7f) with BSMTP id 6111; Tue, 9 Mar 1993 00:40:21 -0500
Date: Sat, 6 Mar 1993 00:58:05 GMT+1
From: Info-IBMPC Digest <[e-mail]>
Subject: Info-IBMPC Digest V93 #34
Sender: Info-IBMPC redistribution list <$$[e-mail]>
To: James Gerber <[e-mail]>
Reply-to: [e-mail]

Info-IBMPC Digest           Sat,  6 Mar 93       Volume 93 : Issue  34

Today's Editor:
         Gregory Hicks - Rota Spain <[e-mail]>

Today's Topics:
           Administrivia: SIMTEL20 subdirectory name changes
             32-BIT FAST SVGA Viewer now available (2 msgs)
                486DX/33MHz *will* run at 40 MHz...but?
                 deleting NON-DOS partitions with fdisk
                  Diskette read errors and data loss.
             DOS 5.0 dosshell task swapper problem (2 msgs)
                Flushing software disk caches (2  msgs)
              how to send a clear screen code to a vt 100
                       Info On Software For Hp95
              In what ways is SIO.SYS better that COM.SYS?
                    MS-DOS 5.0 Environment variables
                need os/2 drivers for IBM music feature
                 Stacker Drive write-protected somehow

Send Replies or notes for publication to: <[e-mail]>

Send requests of an administrative nature (addition to, deletion from
the distribution list, et al) to: <[e-mail]>

Addition and Deletion requests for UK readers should be sent to:
<[e-mail]>

Archives of past issues of the Info-IBMPC Digest are available by FTP
ONLY from WSMR-SIMTEL20.ARMY.MIL in directory PD2:<ARCHIVES.IBMPC>.

----------------------------------------------------------------------

Date: Mon, 22 Feb 1993 11:34:15 -0500 (EST)
From: Keith Petersen - MACA WSMR <[e-mail]>
Subject: Administrivia: SIMTEL20 subdirectory name changes

Effective immediately the following WSMR-SIMTEL20.Army.Mil
subdirectories have been renamed:

      Old Name               New Name
PD1:<MSDOS.ARC-LBR>      PD1:<MSDOS.ARCHIVERS>
PD1:<MSDOS.TROJAN-PRO>   PD1:<MSDOS.VIRUS>

This corresponds to the following on OAK.Oakland.Edu:

      Old Name               New Name
/pub/msdos/arc-lbr       /pub/msdos/archivers
/pub/msdos/trojan-pro    /pub/msdos/virus

Keith
--
Keith Petersen
Maintainer of the MS-DOS archive at WSMR-SIMTEL20.Army.Mil [192.88.110.20]
Internet: [e-mail]     or      [e-mail]
Uucp: uunet!umich!vela!w8sdz                         BITNET: w8sdz@OAKLAND

------------------------------

Date: 16 Feb 93 14:30:48 GMT
From: Turgut Kalfaoglu <[e-mail]>
Subject: 32-BIT FAST SVGA Viewer now available

I am happy to announce that I have just uploaded the FASTEST GIF viewer
available today to ftp-os2.nmsu.edu.It is in /pub/uploads directory.
The filename is GIF32V10.ZIP.

The author, Joe Armengau <[e-mail]> has asked me to upload it
and to let you all know about it.

The program is a 32-bit application that uses pre-fetching and
pre-decoding to speed up the display of the GIF files. It supports all
modes available to your card -- but you have to run the SVGA ON
command from a full-screen DOS prompt (once) to let the program know of
your SVGA modes..

Regards, -turgut

------------------------------

Date: 17 Feb 93 15:07:36 GMT
From: [e-mail]
Subject: 32-BIT FAST SVGA Viewer now available

 Darrel Hankerson writes:
> Turgut Kalfaoglu <[e-mail]> writes:
>>upload of Armengaud's viewer to hobbes~
>>It supports all modes available to your card -- but you have to run
>>the SVGA ON command from a full-screen DOS prompt (once) to let the
>>program know of your SVGA modes..

>Is this accurate? I have a paradise with 512k (which can do
>640x480x256 with cshow, Windows, ect.). This is not a supported card in
>the OS/2 2.1 beta (I think Sipples has said that 512K usually means
>no-go in OS/2 svga modes.)

A lot of problem have indeed been reported with 512Kb adapters.
Hopefully those problems will be fixed in the 2.1 Golden version.

>But svga does recognize the modes. Armengaud's viewer, however doesn't
>seem to like 640x480x256 (I get a blank full-screen session; if I esc,
>then I never return to this blank screen).

>His viewer does work (fast!) in 320x200x256.  Any comments?  Is the
>precise stmt "...all modes REALLY supported by OS/2" ?

Yes, exactly: this is really "all modes supported by BVHSVGA.DLL".
Available modes are read directly from the the SVGADATA.PMI.  Then the
VioSetMode() API is used to switch to these modes.  This API is
implementeducn BVHSVGA.DLL (or BVHVGA.DLL, if SVGA is OFF).

And ALSO A VERY IMPORTANT PRECISION, since it was not very clear: it
only supports SVGA adapters, not coprocessor-based one, like XGA, 8514,
S3.... Of course if you send me an ISA XGA-2 adapter, I will support it
in the next hour :-))

     -Joel Armengaud

------------------------------

Date: 10 Feb 93 03:37:15 GMT
From: james shoemaker <[e-mail]>
Subject: 486DX/33MHz *will* run at 40 MHz...but?

[e-mail] writes:

> Last week I posed the question:  Can a 486DX/33MHz machine be *made* to run
> at 40MHz or even 50MHz?
>
> The responses varied from "No way, Don't do it!" to "Definitely."
>The general concensus was YES, A 486DX/33MHz CAN DO 40MHz PROVIDED
>ADEQUATE COOLING IS PROVIDED.  It was suggested that a heat sink be
>mounted on the 486 and a good fan be used to dissipate the heat.  I
>even heard from some who actually made upgrades to their 286 and 386
>systems in this way, with success.  However, I heard from NOBODY who
>did this to their 486.  So, before I make the plunge, who, if anybody,
>out there has *actually* made this modification to their 486DX/33MHz
>machine, that is, who replaced the 33 MHz oscillator in their 33MHz
>machine with a 40 MHz oscillator, and can still talk about it???  In
>theory, it would seem that the CPU would just run a bit hotter because
>of the faster switching times.  Mind you, the 486 does get hot enough
>to fry an egg on already!

        I am currently running such a beast, though I am not
responsible for its creation.  I bought it from a manufacturer who
before the invention of the DX50 took the CPU's they bought and sorted
out the ones that would go 40Mhz then added this nifty heat-sink/fan
assembly then sold them as 40Mhz 486's.  I have had no problems with
mine so far, in fact with the fan and heat sink the CPU runs cooler
than the 486-25 I used to use at work (Upgraded to a 50 that runs hot
enough to blister now).  One caviat, When you increase the clock either
you need to insert more wait-states in the RAM's or go to faster DRAMS
(My 40 uses 60NS SIMMS), in fact you may have to insert 1 wait state
into some of the slower CACHE memory chips, at least my 50 at work
needs 1 wait state on the SRAM cache to run.

       Hope that is the kind of information you wanted, It can be done,
but be careful.

                                               JWS

------------------------------

Date: 20 Feb 93 07:06:54 GMT
From: Jen Kilmer <[e-mail]>
Subject: deleting NON-DOS partitions with fdisk

[e-mail] (Jojie R. T.) writes:
[e-mail] (Jen Kilmer) writes:
>>
>>>How do you get rid of a non DOS partition without a low level format?
>>
>>Use Norton's or something similar to directly edit the partition table.
>>Or, Microsoft msdos support has written instructions on how to erase all
>>partitions using debug, I could post it if people want.
>
>Why not have them try fdisk /mbr first instead of going out and trying to
>locate a Norton's or something.

"or something"? Debug is _in_ dos. I find it quite handy for editing
partitions.

>Coming from Microsoft, I'm surprised you
>didn't offer this as a possible solution.

Hmmm. You cut out my instructions on using the msdos 5 fdisk to delete
a non-dos partition...a feature added in 5, btw...and the /mbr switch
was added in 5 too.  Not that the /mbr switch strictly exists to erase
partition table data. Normally it doesn't.  All of which makes me
wonder what your point is ;)

What fdisk /mbr does do is write microsoft's version of the master boot
code, which is the code that figures out which partition is bootable
and tries to boot from that partition.  It's not supposed to erase
partition table entries.

/Mbr can erase partition table entries by ACCIDENT, if you partitioned
other than plain fdisk (specially modified fdisk from hardware
manufacturer, or Disk Manager, etc) and a partition entry ended up
where fdisk is writing the boot code, or if the "55 AA" partition table
signature is missing.  /Mbr can also seriously hose any system with a
proprietary type of master boot code - lots of hard disk security
programs use these, so do some dual-boot systems. For example, some pc
flavors of unix need more than just a 1-sector bootstrap loaded by the
master boot code, and microsoft's loads on the 1st sector.

The 5.0 upgrade setup program is much more careful about this (detects
extra partition table entries and some proprietary mbrs) BEFORE it
writes the same boot code that fdisk /mbr does. It also makes a backup
of the old boot code on the uninstall disk, and uninstalling will put
the old code back...something which has come in handy more than once.
Of course, installing 5 to floppy and then manually installing to the
hard disk avoids changing the mbr.

None of this should be considered official microsoft commentary.

-jen

--
[e-mail]
#include <stdisclaimer>
msdos testing

------------------------------

Date: 18 Feb 93 11:53:41 GMT
From: Frank Slootweg CRC <[e-mail]>
Subject: Diskette read errors and data loss.

  Since there were no more responses in about two weeks, it is probably
the right time to post a summary of the News and e-mail responses,
along with my own additional findings.

Summary :
=========

  A summary of the responses, with some comments from me:

- Most responses indicated a possible problem in the diskette
  drive/controller/cable *when writing* :
  - Drive (2 responses).
  - Controller (2).
  - Power supply (1).
  - Loose controller cable (1).
  - Broken controller cable (1).
  - Weak write signal (1).
  - Bad writes after long seeks (1).
    I wrote a program which does the following:
    - seek to (logical) track 159, write/read/compare
    - seek to track   0, write/read/compare
    - seek to track 158, write/read/compare
    - seek to track   1, write/read/compare
    - etc.
    This program gave no errors on a TDK disk. I did not try this test
    on any of the disks which had been bad before.
  - Revolution speed (1).
    I checked the revolution speed with the "Test Drive" (TESTDR14.ZIP)
    "Comprehensive floppy drive diagnostics utility" program from SIMTEL
    (directory PD1:<MSDOS.DSKUTL). The revolution speed was exactly 300
    RPM (as it should be).
  - Dirty environment/head (3).
- Broken DMA controller (1).
- Magnetic fields, diskettes too close to monitor (1).
  Not applicable (see previous response in News).

  I do not want to discard any of the above mentioned possiblities, but
none of them can explain why I have problems, while my son does not
have any problems with the same system, same brands of diskettes and
same "exchange with other systems" behaviour.

New information:

  *New information* which I have not posted before (because I did not
realize/know) :

- All but one of the bad sectors were on (physical) tracks ranging from
track 42 through 79. One bad sector was on track 8.  Since higher
numbered tracks have a smaller diameter than lower numbered tracks, the
density per unit of length is higher, which again might indicate a
problem in the drive.

- *All* of the bad sectors were on head/side 1 (other head/side is 0)!
This might indicate a dirty/misaligned head 1, but again it does not
explain why my son does not have problems, and why I have problems with
diskettes which were written on my system, but can exchange diskettes
with other systems just fine (When a head is misaligned, one can
normally read a diskette on the system on which it was written, but
exchanging diskettes may give problems.).

How to "verify the 'fix'"?

  As said before, I can not determine if any of the above possiblities
is the cause, because the interval between one diskette going bad and
the next (or the same) diskette going bad is too long, weeks to months.

Options:

  The only, not very attractive, options I (think I) have are:

- Buy a special Dysan diagnostic disk (about $60) and the full version
of "Test Drive" (about $50, the version on SIMTEL can only fully test
360KB/5.25" drives). This should be able to tell if my drive is OK or
not, including alignment, etc.. For this money I might as well buy a
new diskette drive, BUT :

- Buy a new diskette drive. However, who will guarantee me that this
drive is OK? My existing drive takes weeks/months to fail, how can
anyone prove that the new drive is good/better?  Also, as some of the
respondents said, the problem *may* be in the controller, cable, DMA
controller, or power supply. I can of course not justify to replace all
of these too.

Conclusion:

  Again I can only assume/conclude that:

- I have just a bad batch of JVC diskettes (all but one with batch
number H971458RY, and one with (probably, hard to read) batch number
H972688RY),

- and just one bad TDK diskette (with batch number JB907B0106),

- while my son just has one diskette from the "bad" JVC batch
(H971458RY), which until now did not give a problem.

  Thanks for all the responses. If anyone has anything to add, suggest,
comment, etc., then please speak up.

Frank Slootweg

------------------------------

Date: 14 Feb 93 05:05:14 GMT
From: "Michael C. Bednar" <[e-mail]>
Subject: DOS 5.0 dosshell task swapper problem.

Hi all,

        I just finished building a 386sx and loading DOS 5.0. While
exploring this new (to me) operating system, I chanced across dosshell.
The only thing that seemed remotely interesting to me is the task
swapper so I tried to run it. The only problem is that when I return to
a swapped task from dosshell, all I get is a blank, grey screen. When I
delete the task, DOS reports that it is still active. My system config
is as follows:

        386sx-33 mb w/4 megs ram, I have EMM386 installed with the the
commandline option of 3072. I have HIMEM.SYS installed.  My display is
a Packard Bell EGA freq. switching monitor and a Legacy Renaissance
card w/256k. This card also has an inport mouse port that I am using
with DOS's mouse.com mouse driver.  Since I am using EGA I have EGA.SYS
installed. I am using DOS's ANSI.SYS ansi driver.

I have tried moving EGA.SYS into high memory, low memory and even
leaving it out. I have tried different ansi drivers. I have tried
reconfiguring EMM386 in case dosshell was looking for XMS memory. I
have tried running dosshell in different screen modes (text and
graphic). Every case leaves me with the same problem. I start a task,
CTRL-ESC back to dosshell and when I re-select the task, all I get is a
blank, grey screen. I can switch back to dosshell with no problems.

        Anyone have any ideas or heard of a possible fix that I've
overlooked?
                                                Snuffy

| Internet: [e-mail]  [e-mail]  Bitnet: VENGER@PITTVMS |

------------------------------

Date: 16 Feb 93 01:11:20 GMT
From: Joe Morris <[e-mail]>
Subject: DOS 5.0 dosshell task swapper problem.

[e-mail] (Michael C. Bednar) writes:

>       I just finished building a 386sx and loading DOS 5.0. While
>exploring this new (to me) operating system, I chanced across dosshell.
>The only thing that seemed remotely interesting to me is the task
>swapper so I tried to run it. The only problem is that when I return to
>a swapped task from dosshell, all I get is a blank, grey screen. When I
>delete the task, DOS reports that it is still active. My system config
>is as follows:

Check to see if you have the fixed version of DOSSWAP.EXE on your
system.  The fixed copy should carry a date later than 4-9-91.  The
actual date of a fixed version may vary depending on how you got it.
The file fixes some failures involved in DOSSHELL swapping.

The fix should be available from MS; ask for MS-DOS tech note PD0445.

Joe Morris / MITRE

------------------------------

Date: 22 Feb 93 02:18:00 GMT
From: Jeremy Laidman <[e-mail]>
Subject: Flushing software disk caches
Keywords: cache

[e-mail] (Robert K Jung) writes:

>I would like to know if there is a standard MSDOS function that will
>cause any resident disk cache like PCKWIK or SMARTDRIVE to flush their
>contents to the physical drive.  This is especially important when
>writing data to a floppy disk.  I have been experimented with DOS 0x0D
>disk reset, but I do not know if disk caches will cooperate with the
>MSDOS buffer flush.

The bios interrupt to reset the harddrive works for most cache
programs, there is a notable exception in Norton Utilities NCACHE.
Ralf Brown's next interrupt list will include my additions regarding
this.  Essentially, the Norton utilities have their own int 2F handler,
which you call with all sorts of perculiar parameters.  By
trial-and-error I found the call to flush the NCACHE buffers.

    mov ax,0xFE00h      ; install check
    mov di,'NU' ; norton utilies
    mov si,'CF' ; ncache-f
    int 2Fh
    cmp si,'cf'
    jne noCache

    mov ax,0xFE03h      ; flush for ncache-f
    mov di,'NU'
    mov si,'CF'
    int 2Fh

:noCache
; now do the bios HD reset

It's a pity Norton didn't hook the bios reset, I think all caches
should do this.

Hope this helps

Jeremy Laidman, Analyst Programmer
School of I.T. and Mathematics                 Phone: [phone]
Edith Cowan University                         Fax:   [phone]
Perth, Western Australia                       [e-mail]

------------------------------

Date: 22 Feb 93 03:31:47 GMT
From: Stan Brown <[e-mail]>
Subject: Flushing software disk caches
Keywords: cache

 [e-mail] (Robert K Jung) writes:
>I would like to know if there is a standard MSDOS function that will
>cause any resident disk cache like PCKWIK or SMARTDRIVE to flush their
>contents to the physical drive.  This is especially important when
>writing data to a floppy disk.  I have been experimented with DOS 0x0D
>disk reset, but I do not know if disk caches will cooperate with the
>MSDOS buffer flush.

It is not clear to me whether you mean "standard DOS function" in the
sense of something you call with INT 21, or in the sense of a command
that the user would type.  In the latter sense, the answer is RTFM.
For example, "smartdrv /c" will do this if the cache program is
SMARTDRV.

In the former sense, INT 21-something, I believe the FAQ covers all the
bases.  Here's the relevant section, from Q701:

    There are two methods of signaling the cache to flush its buffers:
(1) simulate a keyboard Ctrl-Alt-Del in the keystroke translation
function of the BIOS (INT 15 function 4F), and (2) issue a disk reset
(DOS function 0D).  Most disk-cache programs hook one or both of those
interrupts, so if you use both methods you'll probably be safe.

    When user code simulates a Ctrl-Alt-Del, one or more of the
programs that have hooked INT 15 function 4F can ask that the key be
ignored by clearing the carry flag.  For example, HyperDisk does this
when it has started but not finished a cache flush.  So if the carry
flag comes back cleared, the boot code has to wait a couple of cluck
ticks and then try again.  (None of this matters on older machines
whose BIOS can't support 101- or 102-key keyboards; see "What is the
SysRq key for?" in section 3, "Keyboard".)

    Here's C code that tries to signal the disk cache (if any) to flush:

        #include <dos.h>
        void bootme(int want_warm)  /* arg 0 = cold boot, 1 = warm */ {
            union REGS reg;
            void    (far* boot)(void) = (void (far*)(void))0xFFFF0000UL;
            unsigned far* boottype    =     (unsigned far*)0x00400072UL;
            char     far* shiftstate  =         (char far*)0x00400017UL;
            unsigned      ticks;
            int           time_to_waste;
            /* Simulate reception of Ctrl-Alt-Del: */
            for (;;) {
                *shiftstate |= 0x0C;    /* turn on Ctrl & Alt */
                reg.x.ax = 0x4F53;      /* 0x53 = Del's scan code */
                reg.x.cflag = 1;        /* sentinel for ignoring key */
                int86(0x15, ®, ®);
                /* If carry flag is still set, we've finished. */
                if (reg.x.cflag)
                    break;
                /* Else waste some time before trying again: */
                reg.h.ah = 0;
                int86(0x1A, ®, ®);/* system time into CX:DX */
                ticks = reg.x.dx;
                for (time_to_waste = 3;  time_to_waste > 0;  ) {
                    reg.h.ah = 0;
                    int86(0x1A, ®, ®);
                    if (ticks != reg.x.dx)
                        ticks = reg.x.dx , --time_to_waste;
                }
            }
            /* Issue a DOS disk reset request: */
            reg.h.ah = 0x0D;
            int86(0x21, ®, ®);
            /* Set boot type and boot: */
            *boottype = (want_warm ? 0x1234 : 0);
            (*boot)( );
        }

As always, I'm eager to improve this answer; please email me because I
may miss posted material.

Stan Brown, Oak Road Systems                    [e-mail]

------------------------------

Date: 21 Feb 93 16:48:40 GMT
From: Stan Brown <[e-mail]>
Subject: how to send a clear screen code to a vt 100

 [e-mail] (Tony Nuttall) writes:
>I'm in the middle of writing an application which has to periodically
>send information through com2 to a number of vt100 terminals.  What i
>need to know is the clear and home screen code for vt100 terminal.

You're in luck; the VT100 screens accept all the ANSI codes listed in
your DOS manual under ANSI.SYS (except for setting colors of
course--though reverse video and blinking do work).

For clear screen it's (ESC)[2J where (ESC) stands for ASCII 27--don't
include the parens in the string.  This erases the entire screen and
moves the cursor to position 0,0 (upper left).  To move the cursor
without erasing, use (ESC)[line;columnH e.g. "\033[4;20H" moves to line
5 column 21.  Remember the numbering system is 0-based not 1-based.

Stan Brown, Oak Road Systems                    [e-mail]

------------------------------

Date: Tue, 23 Feb 93 23:45:09 CET
From: Gianni Piccoli <[e-mail]>
Subject: Info On Software For Hp95

I am looking for software for the HP95 Lx (the small palmtop by Hewlett
Packard).  I have heard that perhaps exists a reduced version of
mathcad for it.  Is it true ?  And if yes where can I find more info
about it ?

Thank you for the help.

Gianni Piccoli - Cirie - ITALY
(Internet : [e-mail] )

------------------------------

Date: 19 Feb 93 02:21:47 GMT
From: "Robert J. McNamara" <[e-mail]>
Subject: In what ways is SIO.SYS better that COM.SYS?

 [e-mail] (kevin s coupal) writes:
->I'm running Qmodem in a dos session under os/2 2.0 with the CSD and
->have tried every tweaking of the dos settings to get it to stop losing
->characters when

It should completely eliminate character loss for you...it certainly
did for me.  I don't know if Qmodem is Desqview aware, but if it is you
can get an additional (enormous) performace improvement by running
OS2Speed in your dos box.  With the OS2Speed/SIO.SYS combination I'm
able to run {Commo} (a DV aware program) and GSZ (also DV aware) and do
14.4k transfers in the background and I don't even notice 'em!

So get SIO now...it'll be a definite improvement (make sure you get the
latest).

 Rob McNamara
 [e-mail]

------------------------------

Date: 11 Feb 93 21:32:30 GMT
From: Thariq U Ahmad <[e-mail]>
Subject: MS-DOS 5.0 Environment variables
Keywords: environment SET
Summary: Want to know the SET variable for DOS 5

I'd like to know if anyone out there knows the *full* list of
environment variables that can be set using the SET XXXXXX= command in
the AUTOEXEC.BAT file for MS-DOS 5.0.(i.e. like PATH, PROMPT, DIRCMD
etc.) I know that almost any number of variables can be set depending
on the amount of environment memory set aside and the programs that use
them. But does anyone know all the variables that are used just by DOS
5? IOW, how much can one tweak by using the SET command?

And before anyone tells me to RTFM, I have looked up set, environment
variables and almost all other obvious possibilities in the DOS manual
but have come up fruitless.

Thariq Ahmad

p.s. My apologies if this is a FAFAQ
--
Thariq Usman Ahmad
St. John's College
Oxford OX1 3JP
United Kingdom

------------------------------

Date: Tue, 23 Feb 1993 06:56 CST
From: Richard Warwick <[e-mail]>
Subject: need os/2 drivers for IBM music feature

A friend of mine has asked me to attempt to locate os/2 drivers for the
IBM MUSIC FEATURE CARD.  Do these exist? Anybody got any specific
ideas.  (filenames and ftp sites appreciated)

I've found drivers for the soundblaster in the /pub directory at
ftp-os2.nmsu.edu (AKA HOBBES.nmsu.edu)?  I have looked at
software.watson.ibm.com, but have not found anything for this card.

Thanks,
Richard

| Richard Warwick, Manager of PC Services
| Saint Louis University
| Medical Center Computing Services
| 1402 South Grand Avenue  C308
| St. Louis  MO  63104

------------------------------

Date: Mon, 22 Feb 93 13:21:25 EST
From: Bill Jones <[e-mail]>
Subject: Stacker Drive write-protected somehow

> I was running windows 3.1 and tried to print to a laser printer.  It
> [...text deleted...]

> ( By the way I have stacker installed - so I have aD drive.)
>
> During the intial boot message it said D is write protected run scheck
> /f which is a stacker command.

> I ran scheck /f - it complained about a few files and then hung itself.

>[... Text deleted...]

I had a similar horror story, the first time I tried to use Stacker.
Stacker went about it's business compressing all my files into a
compressed file, then ran into a bad sector, and couldn't complete the
process because it couldn't get the old files out of the way to make a
new stacker disk, then the compressed file it made became corrupted,
and it finally gave up.

It said don't panic, read the manual, but every option mentioned in the
manual bombed out with divide by zero errors due to the corrupted
compressed file, so I eventually lost all my data, which didn't make me
too happy.  A friend had a similar occurrance, and had to re-format his
hard drive, although luckily he had a tape backup.

  Anyway, I think anyone who is thinking of using Stacker should note
these horror stories, and re-consider.  At the very least, I would
recommend against using Stacker unless you are certain that your hard
drive has no defects, and unless you have a tape backup system, and the
time to use it.  Otherwise it is just a matter of time until Stacker
will eat your data.  With the low cost of hard drives now, it seems
much more cost effective to just get an additional or bigger drive,
IMHO.

------------------------------

End of Info-IBMPC Digest V93 #34
********************************
-------